FIG. 1 shows a multiprocessor system 100 of the prior art. The multiprocessor system 100 includes a system bus 110, a plurality of processors 120a, 120b coupled to the system bus 110, a main memory 130 coupled to the system bus 110, and a shared resource 150 coupled to the system bus 110. The main memory 130 includes a semaphore 140 which is used to monitor access to the shared resource 150 by the processors 120a, 120b. The processors 120a, 120b each include a register 125a, 125b. 
In the prior art, the semaphore 140 is implemented by using a location in the main memory 130 whose content the processors 120a, 120b examine to determine whether the shared resource 150 is available for access. Assuming that initially the shared resource 150 is available for access, that is, both the processors 120a, 120b are not using the shared resource 150, then the content of the semaphore 140 would be a “0”, indicating that the shared resource 150 is available for access. Assuming further that the processor 120a needs to access the shared resource 150, then the processor 120a would read the content of the semaphore 140 into its register 125a and then write a “1” into the semaphore 140. Design of the multiprocessor system 100 guarantees that the reading of the semaphore 140 and writing a “1” into the semaphore 140 by the processor 120a, or by any other processor, constitutes one bus transaction. That is, the processor 120a seizes the system bus 110 continuously for both the reading and writing of the semaphore 140. Without this guarantee by design, a race condition may occur. A race condition occurs when at least two processors have access to a shared resource at the same time.
The processor 120a examines the copy of the content of the semaphore 140 which it receives in its register 125a and finds that the copy is a “0”, indicating that the shared resource 150 is currently available for access. The processor 120a accesses the shared resource 150. Assume that while the processor 120a is using the shared resource 150, the processor 120b needs to access the shared resource 150. The processor 120b reads the content of the semaphore 140 into its register 125b and writes a “1” into the semaphore 140. Again, the design of the multiprocessor system 100 guarantees that the reading of the semaphore 140 and writing a “1” into the semaphore 140 by the processor 120b would constitute one bus transaction. The processor 120b then examines the copy of the content of the semaphore 140 which it receives in its register 125b and finds that the copy is a “1” indicating that the shared resource 150 is currently not available for access. The processor 120b would then execute a program loop that includes: (a) reading the content of the semaphore 140 into its register 125a, (b) writing a “1” into the semaphore 140, and (c) examining the copy of the content of the semaphore 140 which it receives in its register 125b. The processor 120b executes the program loop until the copy of the content of the semaphore 140 which the processor 120b receives in its register 125b is a “0”.
When the processor 120a finishes using the shared resource 150, the processor 120a writes a “0” into the semaphore 140. Recognizing that the content of the semaphore 140 becomes a “0”, the processor 120b exits the program loop and accesses the shared resource 150. As a result, no race condition can occur.
While waiting for the shared resource 150 to be released by the processor 120a, the processor 120b keeps reading and writing the semaphore 140. This requires repeated use of the system bus 110. When the number of processors in the multiprocessor system 100 increases, a higher percentage of system bus cycles will be wasted on the processors reading and writing the semaphore 140 to determine when the shared resource 150 is released.
It is the object of the present invention to provide a method and apparatus in which semaphore implementation does not require repeated reading and writing the semaphore and, therefore, effectively increases the system bus throughput.